Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/hacklist/94-04.Z/94-04/[e-mail]_Thu Apr 3 03:00:12 1994.msg

Internet Message Format | 1994-04-30 | 6KB

Received: from internet.wst.com.wst.com ([198.64.82.8]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA14695; Thu, 31 Mar 1994 09:58:27 -0500
Received: by internet.wst.com.wst.com (4.1/SMI-4.1)
    id AA00773; Thu, 31 Mar 94 09:00:13 CST
From: [e-mail] (Alun Jones)
Message-Id: <[e-mail]>
Subject: Re: Closing and reusing sockets
To: [e-mail]
Date: Thu, 31 Mar 94 9:00:12 CST
Cc: [e-mail]
In-Reply-To: <9403310353.AA25427@atlas>; from "[e-mail]" at Mar 31, 94 9:11 am
X-Mailer: ELM [version 2.3 PL11]

After much talk on issues of bind() and connect() and listen() and
sockets whose address is already in use, Paul Brooks added:

> To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed
> before you can connect _from_the_same_port_number_ to the same remote
> machine listening on the _same_remote_port_ - possibly by blocking in
> a lingering close, or using linger to hard-close the connection when
> you're done the first time.

Please note that if you're writing a server, you are most likely
listening for any machine, which is a special remote machine address,
and quite obviously you will not be able to listen for any machine on
that same port until the previous server's job has totally finished.

Alun.
~~~~
From [e-mail] Thu Apr  3 03:07:28 1994
Received: from internet.wst.com.wst.com ([198.64.82.8]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA15965; Thu, 31 Mar 1994 10:04:18 -0500
Received: by internet.wst.com.wst.com (4.1/SMI-4.1)
    id AA00810; Thu, 31 Mar 94 09:07:29 CST
From: [e-mail] (Alun Jones)
Message-Id: <[e-mail]>
Subject: Winsock on top of DOS stacks.
To: [e-mail]
Date: Thu, 31 Mar 94 9:07:28 CST
X-Mailer: ELM [version 2.3 PL11]

Here's an interesting problem - I have my WSACleanup code called in
the OnDestroy part of my CWinApp (you can tell which compiler I'm
using, right?), and it doesn't seem to get called in the situation of
the Windows system being closed.  Now this is obviously a bug in my
program, but it causes an interesting problem that might bear
investigating.

If Windows exits unexpectedly, and yet the DOS subsystem is still
running, and if the underlying TCP/IP stack is a DOS-based system (and
still running), should all connected/listening sockets be closed?
Under at least one implementation, for instance, when going back into
windows, my ftp daemon won't start, because (it claims) the ftp port
is being listened on by some other process (presumably my previous
instance under windows).

If Windows exits cleanly, but applications haven't called WSACleanup,
or closed all their sockets, should the TCP/IP stack underneath be
responsible for noting that there is no process connected with those
sockets, and close them itself?

I'm not (yet) arguing one way or the other - just soliciting comments
as to how this might be achieved - whether it's reasonably easy or
not, and whether it's something that might be put into the standard.

And on an unrelated note, I seem to remember somebody mentioning a
Winsock-a-thon session coming up soon at Microsoft - is anyone going
to be testing some of the shareware programs there, too? (esp. mine!
:)

Alun.
~~~~
From [e-mail] Fri Apr  1 19:39:35 1994
Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA26905; Sat, 2 Apr 1994 01:03:30 -0500
Received: from mailserv-D.ftp.com by ftp.com  ; Sat, 2 Apr 1994 00:40:26 -0500
Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
    id AA02833; Sat, 2 Apr 94 00:39:35 EST
Date: Sat, 2 Apr 94 00:39:35 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Winsock on top of DOS stacks.
From: [e-mail]  (Bob Quinn)
Reply-To: [e-mail]
Cc: Multiple recipients of list <[e-mail]>
Sender: [e-mail]
Repository: mailserv-D.ftp.com, [message accepted at Sat Apr  2 00:39:24 1994]
Originating-Client: hurricane.ftp.com
Content-Length: 1826

>  If Windows exits cleanly, but applications haven't called WSACleanup,
>  or closed all their sockets, should the TCP/IP stack underneath be
>  responsible for noting that there is no process connected with those
>  sockets, and close them itself?

A better way to phrase the question is in terms of tasks, I think.
You could ask: "should sockets persist after their tasks are ended?"
To this, I'd answer no.  Orphaned sockets should be closed by the
stack/DLL.

I know that our current WinSock DLL can leave orphan sockets under
some circumstances after an application has ended.  I've seen this
happen with our DLL if the application GPF's (so Windows doesn't call
the Windows Exit Procedure: WEP() to unload our DLL), or if an
application doesn't call WSACleanup() *AND* there's another WinSock
application execution (so the DLL stays memory resident).  Doing the
"garbage collection" to reclaim orphaned sockets after these
scenarios is definately something high on the list of things that we
plan to address.

>  And on an unrelated note, I seem to remember somebody mentioning a
>  Winsock-a-thon session coming up soon at Microsoft - is anyone going
>  to be testing some of the shareware programs there, too? (esp. mine!

Considering that there're only two days to test what will likely be a
large matrix of applications and WinSock implementations, it is not
likely anyone will be testing anything that doesn't have a body
representing it.

But on the bright side, you can be sure I'll bring your FTP Daemon
and the plethora of other public domain applications along for the
ride.  Proven applications like these are always handy for
benchmarks, if nothing else!

Regards,
--
 Bob Quinn                                             [e-mail]
 FTP Software, Inc.                                No. Andover, MA